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In the Specification: 

Please Amend paragraph 29 beginning on page 8, line 24 as follows: 

The CDS A 30 is an existing security layer configuration for providing a widely-accepted 
set of layered security services defined by Intel Architecture Labs (IAL). Typically, the CDSA 
is implemented in computer software. Briefly, the functions and operations of the CDSA 30 will 
be discussed. The CDSA 30 includes a Common Security Services Manager (CSSM) API 
(application programming interface) that interacts with the applications 22-24 and the editor 25 
to allow the applications 22-24 and the editor 25 to access the security-based services offered by 
the CDSA 30. The CDSA 30 also includes a plurality of service provider modules that offer 
these security-based services. Among the known service provider modules, the CDSA 30 may 
include a Cryptographic Service Provider (CSP) module, a Trust Policy (TP) module, a 
Certificate Library (CL) module, a Data storage Library (DL) module, and an Authorization 
Computation (AC) module, all known in the art. These modules provide services such as 
cryptographic operations including bulk encrypting and digital signature processing, accessing 
remote signing entities such as Certification Authorities (CA), storing certificates and 
cryptographic keys, etc. In addition, the CDSA 30, as known, includes elective module 
managers (EMM) that allow new services to be added easily. Under control of the EMM, new 
services can be added easily in a secure manner by merely providing new service provider 
modules as plug-ins that implement the new services. The process of adding and integrating the 
new service modules as plug-ins into the CDSA 30 is known in the art. More detailed operations 
and functions of the service provider modules and the CSSM API as well as the overall 
architecture of the CDSA 30 can be found at the website of "developer.intel.com/ial/securitv/." 
http://d e v e lop e r.int e l.com/iaysecuritY/ . 

Please amend paragraph 49 beginning on page 16, line 27 as follows: 

Now, one example of a meta data organization usable by the "Remember" interface 16 of the 
HAPI 14 will be discussed in more detail referring to Figs. 3A and 3B. Fig. 3A shows an 



In re: Hind et al. 
Serial No.: 10/051,558 
Filed: January 17, 2002 
Page 3 of 19 

example of a computer form usable in the present invention, and Fig. 3B shows examples of 
(key, value) pairs obtainable from the computer form of Fig. 3 A according to one embodiment of 
the present invention. As shown in Fig. 3 A, assume that a computer form 40 to be filled by a 
user is presented to the user on the device 10. The computer form 40 includes at least two fields 
41 and 42, and a "Submit" button 43 for sending the completed form to an appropriate receiving 
party. The first field 41 is for entering the user ID and the second field 42 is for entering the pass 
code. The form 40 has the URL of "www.ibm.com." "http://www.ibm.com". 

Please amend paragraph 50 beginning on page 17, line 7 as follows: 

Given the form 40, the "Remember" interface 16 may collect meta data from the form 40, 
which are represented as a plurality of (key, value) pairs as shown in Fig. 3B. Particularly, for 
each of the data fields 41 and 42, a meta data group is established wherein the plurality of meta 
data groups constitute a meta data set. Each meta data group includes application data (in this 
case, a field value) and context data associated with that value. For instance, for the user ID field 
41, the meta data group A is established. The meta data group A is composed of application data 
represented by a (key, value) pair 44 and context data represented by (key, value) pairs 45. The 
(key, value) pair 44 indicates that the value V of the field (key) 41 is "MPeters". The context 
data 45 indicates the context in which the field value "MPeters" is used. In this case, the context 
of the field 41 is identified to be as follows: the name of the field 41 is "euser", the description 
of the field 41 is "User ID", the form 40 having the field 41 is called "customerinfo", the URL of 
the form 40 is "http://www.ibm.com", "www.ibm.com," the URL referred in the form 40 is 
"http://www.ibm.product.com", "www.ibm.product.com," and the role of the user (i.e., role in 
which the user functioned in filling out this form) is "manager". Similarly, the meta data group 
B established for the field 42 includes a (key, value) pair 46 indicating that the field value V is 
"123", and context data 47 indicating the context of the field 42. The meta data groups A, B, 
are related to each other and constitute a meta data set wherein all the data belonging to the meta 
data set are related to each other. In this example, the user's role can be collected by requesting 
the user to specify the user's current role, e.g., using a pop-up window, the meta data editor 25 or 
some other means, or can be determined using other available meta data, e.g., by comparing the 
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meta data with similar meta data stored in the database(s) 15. This approach is applicable to 
embodiments discussed herein. 

Please amend paragraph 52 beginning on page 18, line 5 as follows: 

Retrieve best 5 V Context (50%role=manager, 2 5 %URL~http ://\vww . ibm . com 
25%URL-'www.ibm.com," 1 0%descript=User DD, 5%fieldname=euser, 

10%R e fURL^http://vvww.ibm.productxom) 
1 0%RefURL= ,, www.ibm.productxom" > ) ; 

Please amend paragraph 53 beginning on page 18, line 8 as follows: 

Retrieve best 5 V Context (50%role=manager, 25%URL~http ://www.ibm.com 
25%URL- f www.ibm.com, M 10%rescript=Pass Code, 5%fieldname=verification, 

10%RefURL^http://www.ibm.product.com) 
1 0 0 /oRefURL= ^ www.ibm.product.com ,, ) ; 



